In many situations it is desirable to protect digital content against unauthorised access. Encryption of data is a widely used method for achieving such a protection. There is a large variety of known encryption methods providing different degrees of protection against attacks by unauthorised users targeted at breaking the encryption and getting access to the data.
Digital Rights Management (DRM) refers to a range of access control technologies that can be used by hardware manufacturers, publishers, copyright holders and individuals to impose limitations on the usage of digital content and devices. The term is used to describe any technology which controls uses of digital content and, in particular, restricts uses that were not desired or foreseen by the content provider.
A DRM agent is a trusted entity in a processing device, such as a mobile terminal, responsible for enforcing permissions and constraints associated with digital content managed by a DRM system, as well as controlling access to the digital content. The DRM agent is typically launched when protected digital content is received by the device, and it extracts and decrypts the digital content. The DRM agent does normally not decrypt protected content at the point when it arrives to the processing device, as unprotected content must normally not be stored on the processing device. Instead, content is normally decrypted chunk by chunk upon request from a rendering unit (e.g. upon media player requests) and conditioned on applicable permissions and/or constraints.
The DRM agent is consulted for permissions and constraints before the content is passed to a media player or other processing device or program for processing the digital content, e.g. an image viewer, video player, etc.
In a DRM system, it is often desirable to communicate data between two nodes such that the data is protected against interception and tampering.
For example, in home networks a residential gateway is typically the terminating node in communication sessions involving download and rendering of protected content. To enable rendering on other devices in the home network that may not necessarily include complete DRM support, the protected content which is decrypted by the DRM agent in the gateway needs to be securely transmitted to the device.
More generally, the DRM agent may need to involve rendering resources that it can not by default treat as trusted, including cases where these resources are located both in the same device as the DRM agent and cases where these resources are located in another device than the DRM agent.
So-called Secure Authenticated Channels (SAC) are used to transfer data protected against interception and tampering between two nodes. A common method to create a secure channel is for the two nodes to create and share a common secret session key that can be used for encrypting the data sent over the channel. Several options are available for securely establishing this session key. Cryptographic protocols like the Diffie-Hellman key exchange can be used, or if the nodes belong to a Public Key Infrastructure (PKI) system (also referred to as PKI ecosystem), this may be used for a secure key exchange. For the two nodes to authenticate each other, either a PKI ecosystem is required, or the two nodes must share a common pre-loaded secret key (or password).
For two nodes to achieve mutual authentication and establishment of a secure channel, either a PKI ecosystem is needed, or preloaded shared secrets must be available in the nodes.
PKI ecosystems require a substantial investment to be established, and the computational burden on the nodes for running the required algorithms is quite high. Only few usable large-scale PKI systems are in place. Some of them are connected to PKI-based DRM system, for example the PKI system established by CMLA (Content Management License Administrator), for use in OMA DRM standards compliant servers and devices. However, these systems are not foreseen to be used for general SAC establishment, and per se do not support such general functionality.
Preloaded shared secrets require that the nodes have securely received the secret at some point before the secure transfer is to take place. In scenarios where larger numbers of nodes shall support a SAC establishment, one possible solution is to provision the shared secret during the production process of the nodes. This means that the “SAC ecosystems” that the node should support must be known at production time, which reduces the flexibility in what SAC ecosystems a node can participate. Therefore, pre-shared keys (e.g. as used in TLS-PSK) are often used in enterprise applications and systems, but not commonly in CE devices or systems.